البرمجة

إدارة الفروع البعيدة في Git

التعامل مع التفريعات البعيدة (Remote Branches) في Git

يُعد Git من أقوى نظم التحكم في الإصدارات المستخدمة في البرمجة الحديثة، ويعود الفضل في ذلك إلى مرونته العالية وإمكاناته المتقدمة في إدارة الكود المصدري بين فرق العمل المتوزعة. ومن أهم ميزاته قدرته على التعامل مع التفريعات (Branches)، سواء كانت محلية (Local) أو بعيدة (Remote). إن التفريعات البعيدة تُعتبر من اللبنات الأساسية التي تُمكِّن فرق التطوير من التعاون والعمل على ميزات مختلفة ضمن نفس المشروع، دون التأثير على الفرع الرئيسي أو على عمل الزملاء الآخرين.

يهدف هذا المقال إلى تقديم فهم شامل للتعامل مع التفريعات البعيدة في Git، ابتداءً من مفاهيمها الأساسية، مرورًا بكيفية إنشائها وتتبعها، وانتهاءً بكيفية حذفها ومزامنتها، مع تقديم أمثلة عملية وحالات استخدام واقعية تدعم هذا الفهم.


أولًا: ما هي التفريعات البعيدة (Remote Branches)؟

التفريعات البعيدة هي نسخ من الفروع الموجودة على مستودع Git على الخادم (مثل GitHub، GitLab، Bitbucket)، وهي تُستخدم لتعقب التغييرات التي تحدث في مستودع مركزي خارجي. وتُخزن هذه الفروع محليًا في مجلد خاص باسم remotes/ داخل المستودع، حيث يمكن مشاهدتها باستخدام الأمر:

bash
git branch -r

على سبيل المثال، إذا كان اسم الريموت هو origin وكان هناك فرع اسمه develop على الريموت، فستظهر النتيجة بالشكل التالي:

bash
origin/develop

هذا يعني أن هناك فرعًا بعيدًا باسم develop موجودًا على المستودع البعيد المسمى origin.


ثانيًا: الفرق بين الفروع المحلية والبعيدة

النوع الفروع المحلية (Local Branches) الفروع البعيدة (Remote Branches)
الموقع تُخزن في جهاز المستخدم تُخزن في الخادم (GitHub مثلًا)
التحديث يمكن تعديلها مباشرة تحتاج إلى مزامنة لجلب أو دفع التغييرات
الإنشاء تُنشأ بالأمر git branch تُنشأ عند الدفع إلى الريموت أو باستخدام git push
الاستخدام تُستخدم في التطوير اليومي تُستخدم لتعقب العمل الجماعي والتغييرات على الخادم

ثالثًا: إنشاء فرع محلي من فرع بعيد

لإنشاء فرع محلي يتتبع فرعًا بعيدًا، يتم استخدام الأمر:

bash
git checkout -b my-feature origin/my-feature

هذا الأمر يقوم بما يلي:

  • إنشاء فرع محلي باسم my-feature

  • ربطه بالفرع البعيد origin/my-feature ليقوم بتتبعه تلقائيًا

  • التبديل إلى الفرع الجديد

وبذلك يصبح الفرع المحلي على علم بكل التغييرات القادمة من الفرع البعيد الذي يتبعه.


رابعًا: جلب التحديثات من الفروع البعيدة

عندما يعمل أكثر من شخص على نفس المشروع، قد تحدث تغييرات في الفروع البعيدة. لجلب آخر التحديثات دون دمجها تلقائيًا، يتم استخدام:

bash
git fetch

هذا الأمر يقوم بتحديث جميع الفروع البعيدة المخزنة محليًا من دون التأثير على حالة الفروع المحلية الحالية.

وإذا كان المطلوب جلب التحديثات من ريموت معين فقط:

bash
git fetch origin

وبعد تنفيذ fetch، يمكن مقارنة التغييرات أو دمجها يدويًا حسب الحاجة.


خامسًا: تتبع الفرع البعيد عند الإنشاء

في بعض الأحيان، يُرغب بإنشاء فرع محلي يتبع فرعًا بعيدًا بشكل مباشر، ويمكن فعل ذلك باستخدام:

bash
git checkout --track origin/feature-x

هذا الأمر يُنشيء فرعًا محليًا اسمه feature-x ويجعله يتتبع الفرع البعيد origin/feature-x.

وهناك أيضًا الطريقة الأقصر باستخدام:

bash
git checkout feature-x

لكن ذلك مشروط بوجود فرع بعيد واحد فقط يحمل الاسم feature-x.


سادسًا: دفع فرع محلي ليصبح فرعًا بعيدًا

عند إنشاء فرع محلي جديد وترغب في رفعه إلى الريموت ليكون متاحًا للآخرين:

bash
git push -u origin my-new-branch

الخيارات المستخدمة هنا تعني:

  • origin: اسم الريموت

  • my-new-branch: اسم الفرع المحلي

  • -u: يربط الفرع المحلي بالبعيد لتسهيل تنفيذ أوامر pull وpush مستقبلًا بدون تحديد الاسم الكامل للفرع

بعد هذا الإجراء، يمكن ببساطة استخدام git push أو git pull في هذا الفرع دون الحاجة إلى تحديد الريموت والفرع كل مرة.


سابعًا: حذف فرع بعيد

لحذف فرع من المستودع البعيد:

bash
git push origin --delete old-branch

هذا الأمر يُستخدم في حال تم الانتهاء من العمل على فرع معين ولم تعد هناك حاجة له على الخادم.

بعد تنفيذ هذا الأمر، يمكن استخدام git fetch -p (أو --prune) لتنظيف الفروع البعيدة المحذوفة من قائمة الفروع المحلية.


ثامنًا: تحديث الفروع البعيدة المحلية

عندما يُحدث أحد الزملاء فرعًا بعيدًا أو يحذفه، يجب مزامنة المستودع المحلي للحصول على هذه التحديثات:

bash
git fetch --prune

هذا الخيار يقوم بجلب جميع الفروع البعيدة وتحديث حالة الفروع المحذوفة، مما يضمن أن قائمة الفروع المحلية تعكس تمامًا ما هو موجود في المستودع البعيد.


تاسعًا: إعادة تسمية الفروع البعيدة

إعادة التسمية للفروع في Git تتم بشكل محلي أولًا ثم على الريموت. لعمل ذلك:

  1. إعادة تسمية الفرع المحلي:

bash
git branch -m old-name new-name
  1. حذف الفرع القديم من الريموت:

bash
git push origin --delete old-name
  1. رفع الفرع الجديد:

bash
git push -u origin new-name

عاشرًا: مقارنة الفروع المحلية بالبعيدة

لمعرفة الفروقات بين الفرع المحلي والفرع البعيد الذي يتبعه:

bash
git fetch git diff origin/my-branch

أو لمعرفة عدد الـ commits التي تختلف بها الفروع:

bash
git log --oneline my-branch..origin/my-branch

هذا يُظهر الكمّية والنوعية الدقيقة للاختلافات، ويمكن استخدامه قبل عمليات الدمج أو الدفع للتأكد من حالة التفرع.


حادي عشر: التعامل مع أكثر من ريموت واحد

من الممكن أن يحتوي مشروع Git على أكثر من ريموت (مثل origin, upstream). ويتم ذلك باستخدام:

bash
git remote add upstream https://github.com/other/repo.git

ثم يمكن تنفيذ عمليات fetch، pull، أو push إلى الريموت الجديد:

bash
git fetch upstream

أو:

bash
git pull upstream main

يُستخدم هذا في حالات كثيرة مثل:

  • عندما يكون هناك مستودع رئيسي (upstream) ومستودع خاص بالتطوير (fork)

  • عند إدارة نسخ متعددة من المشروع لجهات مختلفة


ثاني عشر: جدول ملخص لأوامر Git الشائعة مع الفروع البعيدة

المهمة الأمر المستخدم
عرض الفروع البعيدة git branch -r
إنشاء فرع محلي يتبع فرعًا بعيدًا git checkout -b branch-name origin/branch-name
جلب التحديثات من الريموت git fetch أو git fetch origin
رفع فرع جديد إلى الريموت git push -u origin branch-name
حذف فرع بعيد git push origin --delete branch-name
تتبع فرع بعيد بشكل مباشر git checkout --track origin/branch-name
تنظيف الفروع البعيدة المحذوفة git fetch --prune
مقارنة فرع محلي بفرع بعيد git diff origin/branch-name

ثالث عشر: ممارسات موصى بها عند التعامل مع الفروع البعيدة

  • تسمية الفروع بشكل واضح: يجب أن تعبر الأسماء عن الغرض منها مثل feature/login-form أو bugfix/payment-error.

  • التنظيف الدوري: من الضروري حذف الفروع التي انتهى استخدامها من الريموت لتجنب التكدس.

  • الاعتماد على fetch بانتظام: جلب التحديثات يضمن مزامنة الحالة دون التسبب بتغييرات مفاجئة في الكود.

  • عدم الدفع مباشرة إلى الفرع الرئيسي: يُفضل العمل على فروع منفصلة ودمجها لاحقًا بواسطة Pull Requests لمراجعة الكود.

  • التحقق قبل الدمج: يُوصى دائمًا بمقارنة الفروع قبل عمليات الدمج (merge) لتفادي تعارضات غير متوقعة.


المصادر والمراجع